To improve the performance of a computer system, an Input/Output (I/O) processor may be added to off-load various I/O processing chores. FIG. 1 is a block diagram illustrating an I/O processor 100 and related subsystems. The I/O processor communicates with a host computer system (not shown in FIG. 1) over a primary bus 90. A bus that complies with a Peripheral Component Interconnect (PCI) standard (e.g., PCI Local Bus Specification, Version 2.1, a copy of which may be obtained from the PCI Special Interest Group) is an example of such a primary bus. The I/O processor 100 also communicates with various I/O subsystems 110, 120, 130, such as a network interface card or a hard disk drive, or "disk," subsystem 110, over a secondary PCI bus 95. The I/O processor may also communicate with a local memory 140, generally by using a memory controller.
When the host computer system transfers data with, for example, the disk subsystem 110, the I/O processor 100 may store a copy of the transferred data in the local memory 140. If so, the local memory 140 will contain any data that was recently transferred between the host computer system and the disk subsystem 110. This data in the local memory 140, known as a "cache," may be accessed by the I/O processor 100 faster than the data in the disk subsystem 110.
When the I/O processor 100 receives another request to transfer data between the host computer system and the disk subsystem 110, the I/O processor 100 looks first in the local memory 140 cache. If the data is already there, the I/O processor 100 avoids the time consuming task of accessing the disk subsystem 110. This allows for significantly enhanced I/O and system level performance. Such a cache may be used, for example, in server applications for either networking or storage information. Specifically, an application may use the I/O processor 100 and 128 megabytes (Mb) of local memory 140 to improve the performance of a Small Computer System Interface (SCSI) Redundant Array of Independent Disks (RAID) disk subsystem 110.
One disadvantage of such a cache system is that it assumes that all data sent to the I/O processor 100 is eventually stored on the non-volatile disk subsystem 110. If the data was not moved from the local memory 140 to the disk subsystem 110, the data may be lost if a system power failure occurs which causes the volatile local memory 140 to power down. Thus, the local memory 140 should retain the disk cache data, also referred to as the "memory image"--even in the event of a power failure. To allow this, the local memory 140 may be supplied with battery-backup power.
Certain memory types, such as Dynamic Random Access Memory (DRAM), store information in cells using a capacitor and a transistor. Because a capacitor may lose its electrical charge rather quickly, the DRAM is continuously given a new electric charge, or "refreshed," every few milliseconds (msec).
Consider a local memory 140 that uses DRAM. The refresh function is usually performed by a memory controller in the I/O processor 100. If the entire system loses power, such as during a power outage or when a power supply fails, the memory controller may also lose power. In this case, the memory controller will be unable to refresh the DRAM. Even if the DRAM has battery-backup power, the memory image will be lost if the DRAM is not constantly refreshed. Therefore, some I/O processor designs include an external agent, such an Application Specific Integrated Circuit (ASIC) component with battery-backup power, that refreshes the DRAM in the event of a power failure. Unfortunately, ASIC components are expensive and must be specially designed for a particular system.
Some memory types that need constant refreshing also have a "self-refresh" mode. Synchronous DRAM (SDRAM) is such a memory type. When the memory controller sends the SDRAM a self-refresh command, the SDRAM will continuously refresh itself autonomously with internal logic and timers. A self-refresh feature may be used, for example, to implement a low power mode in a lap-top computer. In such a system, the SDRAM refreshes itself when the memory controller is intentionally powered-down to extend battery life. Because memory contents don't need reloading when the lap-top computer leaves the low power mode, the system can rapidly return to normal operation. The SDRAM self-refresh feature has only been used with respect to intentional low-power modes, not power failures.
In view of the foregoing, a need exists for a method and apparatus that retains information in a local memory system during a power failure, and solves the other problems discussed above.